Can you explain what rollup is and why we should use it?

Anyways, I agree with most of your points. We definitely should restructure code at the same time as translating it form CoffeeScript to JS, which is precisely why automating that task is only somewhat helpful.

Circular dependencies are spread all over the codebase:

Yeah, that's pretty bad...

Many unresolved dependencies:

Eh, those are whatever -- in theory we shouldn't rely on those being in the global context (just like the atom global, I suppose), but in practise that really doesn't matter much.

Use named exports/imports
Stop using dynamic require.

👍

Don't try to do everything in one package. Use services from other packages like linter, atom-ide packages, etc. Modularity is the best development approach.

Eh, not so sure about that. Most Atom packages aren't that great to interface with (and/or provide an awful UX). atom-linter is probably the exception there, and we should use it once we actually have a linter (and for the Traceur integration, I suppose).

deferring execution should be the last thing to try. The program should already run fast synchronized and then could benefit from asynchronous execution.

Hm, not sure what you mean here. I think we should make sure to (re-) design everything with lazy-loading and as much asynchronicity in mind -- it's pretty hard to shoehorn that in afterwards without making a mess of everything.

and lastly, be open to suggestions. People want to help.

👍
But also appreciate that we don't have an unlimited amount of time to work on this (and even reviewing PRs takes a lot of time when they touch huge parts of the codebase). I also think performance isn't the biggest problem Juno has right now.

Can you explain what rollup is and why we should use it?

It is a bundler similar to Webpack, but with better plugins. It reduced the load time (even now that the code has many issues) to half of its time. So once the Junos requires are converted to import,export, you can get a huge bump in the performance.

Don't try to do everything in one package. Use services from other packages like linter, atom-ide packages, etc. Modularity is the best development approach.

Eh, not so sure about that. Most Atom packages aren't that great to interface with (and/or provide an awful UX). atom-linter is probably the exception there, and we should use it once we actually have a linter (and for the Traceur integration, I suppose).

atom-ide-community packages are very well. linter is very good too. If there is something you don't like about them, you should improve those packages instead of writing everything from scratch here.

deferring execution should be the last thing to try. The program should already run fast synchronized and then could benefit from asynchronous execution.

Hm, not sure what you mean here. I think we should make sure to (re-) design everything with lazy-loading and as much asynchronicity in mind -- it's pretty hard to shoehorn that in afterwards without making a mess of everything.

Here I meant relying on deferring execution isn't good when the codebase already has other issues. It should be tried after.

and lastly, be open to suggestions. People want to help.

👍
But also appreciate that we don't have an unlimited amount of time to work on this (and even reviewing PRs takes a lot of time when they touch huge parts of the codebase).

That is why you opened the source of the packages. People will put time on helping the package improve.

I also think performance isn't the biggest problem Juno has right now.
Writing good code is always important, even if you don't care about performance. The things I mentioned are not that complicated, most of them are a matter of just replacing a few lines of code.

Regarding the Atom's performance, people complain about it all over the internet. Many (including the actual Atom developers) have already switched to other platforms! We should all write performant code, especially when we gain a lot with very minor adjustments (like import and require).